Skip to content

Strip embedded Project-Id-Version content from GNU message catalog type - #54

Open
Jbansal2 wants to merge 1 commit into
aboutcode-org:mainfrom
Jbansal2:fix-mo-file-type-leaks-content
Open

Jbansal2 wants to merge 1 commit into
aboutcode-org:mainfrom
Jbansal2:fix-mo-file-type-leaks-content

Conversation

@Jbansal2

Copy link
Copy Markdown

Fixes #43.

For .mo files (GNU message catalogs), libmagic's detected type string
can include the gettext PO header's Project-Id-Version field verbatim,
e.g.:

GNU message catalog (little endian), revision 0.0, 349 messages, Project-Id-Version: django '%(datetime)s non se puido interpretar na zona hora horaria %(current_timezone)s; pode ser ambiguo ou non existir.'

That trailing part after Project-Id-Version: is free-form content taken
directly from inside the scanned file (translator comments, escaped
non-ASCII bytes, etc.), not structural type information, so it was
leaking into filetype_file and anything derived from it (as reported
against the two Django .mo files linked in the issue).

Change

In magic2._detect(), right after decoding and collapsing whitespace on
libmagic's raw output, strip any trailing Project-Id-Version: ... that
follows the structural GNU message catalog (...), revision X, N messages
description, via a regex matched only against that specific pattern so no
other file type strings are affected.

Tests

Added tests/test_magic2.py cases that exercise the stripping regex
directly against both leaked strings quoted in the issue (the plain-text
one and the escaped-byte one) and confirm unrelated type strings
(ASCII text, an ELF description) pass through unchanged.

Verification note

This sandbox doesn't have a working typecode-libmagic plugin install
(module import fails before even reaching this code, on an unrelated
plugincode entry-point issue in this environment), so I couldn't run
file_type() end-to-end against real .mo files here. I verified the
regex logic in isolation against the exact strings quoted in the issue
(including the escaped-byte example) and against unrelated type strings,
and the new tests encode that same verification so they'll run in CI.

libmagic's description for GNU message catalog (.mo) files can include
the gettext PO header's Project-Id-Version field verbatim, which is
free-form content taken from inside the scanned file (translator
comments, escaped non-ASCII text, etc.) rather than structural type
information. This leaked raw file content into filetype_file and
anything derived from it.

Strip that trailing Project-Id-Version content in _detect() right
after decoding libmagic's output, keeping only the structural
'GNU message catalog (...), revision X, N messages' description.

Added tests/test_magic2.py cases covering both leaked examples from
the issue (plain text and escaped-byte Project-Id-Version values) and
confirming unrelated file types are left untouched.

Fixes aboutcode-org#43

Signed-off-by: Jitendra Bansal <jitendrabansal0300@gmail.com>
@Jbansal2

Copy link
Copy Markdown
Author

The run_code_checks (doc8) and top-level build failures aren't from this PR's diff — doc8 is failing on pre-existing trailing whitespace in CHANGELOG.rst line 8, introduced by the Bump version and CHANGELOG to v30.2.0 release commit (4795fee) that's already on main. All 6 platform test matrices (macOS 14/15, Ubuntu 22/24, Windows 2022/2025) pass with this change. Happy to also fix the CHANGELOG whitespace here if that's preferred, just didn't want to bundle an unrelated fix into this diff without asking.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

File type of *.mo file contains content

1 participant